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Abstract 


This  report  contributes  to  further  development  of  the  Security  Quality  Requirements  Engineering 
(SQUARE)  method  to  address  privacy.  Risk  assessment  is  Step  4  in  the  standard  SQUARE 
process.  This  report  examines  privacy  definitions,  privacy  regulations,  and  risk  assessment  tech¬ 
niques  for  privacy.  The  risk  assessment  techniques  are  classified  using  a  standard  method,  and 
promising  techniques  are  applied  to  two  case  studies.  The  case  study  results  are  provided  along 
with  future  plans  for  SQUARE  for  Privacy. 


ix  I  CMU/SEI-2009-SR-017 


X  I  CMU/SEI-2009-SR-017 


1  Overview 


In  this  report,  we  continue  to  describe  extensions  to  the  SQUARE  method  [Mead  2005]  to  support 
privacy.  This  work  builds  on  earlier  extensions  to  SQUARE  in  consideration  of  privacy  [Miyasaki 
2008a]  and  is  part  of  a  multiyear  plan  to  extend  SQUARE  in  support  of  privacy  (P-SQUARE). 
Since  performing  risk  assessment  is  Step  4  of  the  SQUARE  process,  it  seems  natural  to  examine 
risk  assessment  for  the  special  needs  of  privacy. 

Software -intensive  systems  are  widely  used  for  the  rapid  storage  and  retrieval  of  data.  We  trust 
that  all  types  of  data  will  reside  in  these  systems  and  easily  be  transferred  to  other  systems.  This 
high  level  of  trust  poses  certain  privacy  risks  for  sensitive  information.  If  these  risks  are  identi¬ 
fied,  we  will  be  able  to  understand  the  potential  consequences  and  establish  the  necessary  preven¬ 
tative  measures.  This  report  summarizes  the  assessment  of  risks  while  focusing  primarily  on  pri¬ 
vacy  concerns. 
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2  Definition  of  Privacy 


It  is  necessary  to  clearly  define  the  terms  involved  in  information  privacy.  Without  a  clear  defini¬ 
tion  of  privacy,  it  is  challenging  to  draw  clear  boundaries  between  general  and  specialized  privacy 
risk  assessments. 

We  first  look  at  the  public  dictionary  definitions  of  privacy.  These  definitions  give  us  a  general 
idea  of  the  term  and  shed  some  light  on  potential  meaning  conflicts.  Next,  we  look  more  closely  at 
literature  involving  privacy  risks  to  understand  more  about  the  term,  both  explicitly  and  implicitly 
stated. 

2.1  General  Definition  of  Privacy 

According  to  Wikipedia,  information  privacy  is  defined  as  “the  relationship  between  collection 
and  dissemination  of  data,  technology,  the  public  expectation  of  privacy,  and  legal  issues  sur¬ 
rounding  them”  [Wikipedia  n.d.].  This  source  also  notes  that  “privacy  concerns  exist  wherever 
personally  identifiable  information  is  collected  and  stored — in  digital  form  or  otherwise.  Improper 
or  non-existent  disclosure  control  can  be  the  root  cause  for  privacy  issues.”  Detailed  information 
about  privacy,  including  special  topics  such  as  internet  privacy,  can  be  found  on  the  Wikipedia 
website. 

The  definition  of  privacy  differs  slightly  between  two  dictionaries.  Merriam-Webster  defines  pri¬ 
vacy  as  either  “the  quality  or  state  of  being  apart  from  company  or  observation”  or  “freedom  from 
unauthorized  intrusion”  [Merriam-Webster  n.d.].  The  Oxford  English  Dictionary  defines  privacy 
as  a  “state  in  which  one  is  not  observed  or  disturbed  by  others”  [AskOxford  n.d.]. 

2.2  Privacy  as  Discussed  by  Publications  and  Researchers 

2.2.1  Privacy  as  an  Ability  to  Control  Personal  Information 

In  his  master’s  degree  thesis,  Seiya  Miyazaki  contrasts  two  meanings  of  privacy  [Miyazaki 
2008b].  Privacy  is  defined  by  Turkington  as  “the  ability  of  an  individual  to  control  his/her  own 
information”  [Turkington  1990].  This  is  very  different  from  the  definition  “the  right  to  be  left 
alone”  as  described  in  [Samuel  1890]. 

Microsoft  published  a  set  of  privacy  guidelines  for  software  development.  In  this  document,  they 
state  that  the  core  principle  of  the  guideline  is  that  “Customers  will  be  empowered  to  control  the 
collection,  use,  and  distribution  of  their  personal  information”  [Microsoft  2008]. 

Altman  and  Chemers  [Altman  1984]  conceptualize  privacy  as  a  selective  control  of  access  to  the 
self.  They  propose  a  view  of  privacy  as  a  process  where  degree  of  confidentiality  differs  depend¬ 
ing  on  the  time.  They  also  state  that  people  usually  optimize  their  accessibility  along  a  spectrum 
of  “openness”  and  “closeness”  depending  on  the  operating  context. 


2  I  CMU/SEI-2009-SR-017 


2.2.2  Privacy  as  Freedom  from  Unauthorized  Intrusion 


In  a  study  to  experiment  with  a  lightweight  method  helping  in  privacy-oriented  requirements  elici¬ 
tation,  Jensen  and  Potts  refer  to  “privacy  enhancing  principle  (i.e.,  information  minimization)” 
that  could  augment  the  requirements  [Jensen  2007].  The  suggested  technique  to  enhance  privacy 
in  this  case  implies  that  we  could  establish  measures  to  guarantee  the  security  of  data.  This  paper 
views  privacy  as  freedom  from  unauthorized  intrusion. 

In  a  study  to  create  a  model  to  monetize  the  value  of  privacy  data,  Yassine  and  Shirmonhammadi 
state  that  there  should  be  a  way  to  help  “regulate  the  use  and  the  disclosure  of  confidential  infor¬ 
mation  so  that  consumers’  right  to  privacy  is  protected”  [Yassine  2008].  The  model  also  seems  to 
be  based  on  preventing  the  user’s  data  from  falling  into  the  hands  of  a  malicious  third  party. 

Several  laws  and  regulations  are  written  in  terms  of  protecting  the  privacy  of  the  consumers  or 
service  users.  However,  they  do  not  usually  explicitly  state  the  meaning  of  privacy  but  rather  de¬ 
fine  entities  to  be  protected  and  measures  required  to  be  implemented.  For  instance,  the  Federal 
Privacy  Act’s  purpose  could  be  summarized  as  “primarily  directed  to  Federal  agencies  for  the 
purpose  of  protecting  the  privacy  of  individuals  identified  in  information  systems  maintained  by 
such  Federal  Agencies”  [University  of  California  1992]. 

Unlike  many  other  information  privacy  related  laws,  the  Privacy  Impact  Assessment  Guide  pub¬ 
lished  by  Australia’s  Office  of  the  Privacy  Commissioner  has  a  defined  meaning  of  privacy.  The 
guide  states  that  information  privacy  is  “information  or  an  opinion  (including  information  or  an 
opinion  forming  part  of  a  database),  whether  true  or  not,  and  whether  recorded  in  a  material  form 
or  not,  about  an  individual  whose  identity  is  apparent,  or  can  reasonably  be  ascertained,  from  the 
information  or  opinion”  [OPC  2006]. 

2.2.3  Relationship  Between  Privacy  and  Security 

With  the  definitions  above,  one  can  see  that  privacy  involves  security  concerns,  especially  if  we 
take  the  meaning  that  involves  protecting  information  from  unauthorized  sources.  In  one  paper 
discussing  privacy  risk  assessment  of  a  ubiquitous  computing  system,  Hong  et  al.  explain  the  rela¬ 
tionship  between  security  and  privacy.  They  cite  the  work  of  Saltzer  and  Schroeder,  which  defines 
security  as  “mechanisms  and  techniques  that  control  who  may  use  or  modify  the  computer  or  the 
information  stored  in  it”  and  privacy  as  “the  ability  of  an  individual  (or  organization)  to  decide 
whether,  when,  and  to  whom  personal  (or  organizational)  information  is  released”  [Hong  2004]. 

Given  this  definition,  it  is  clear  that  security  may  be  one  of  the  key  components  to  ensure  that  a 
user  can  restrict  access  from  certain  sources.  However,  we  can  see  that  it  is  not  sufficient  to  grant 
total  control  to  the  user. 
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3  Definition  of  Privacy  for  Risk  Assessment 


As  we  can  see  from  various  works,  there  is  no  universally  agreed  upon  definition  of  privacy.  Even 
the  works  that  address  information  privacy  specifically  still  have  some  conflicts  about  its  mean¬ 
ing.  Papers  about  risk  assessment  tend  to  focus  more  on  controlling  personal  information  than  on 
limiting  access. 

While  there  is  no  significant  drawback  to  the  traditional  meaning  of  privacy,  it  is  limiting  for  the 
purpose  of  risk  assessment.  As  stated  in  their  paper  about  privacy  methods,  laChello  and  Abowd 
commented  that  “these  efforts  have  usually  taken  a  normative  and  systems-oriented,  rather  than  a 
user-centered,  approach  and  have  served  well  to  regulate  industrial  uses  of  personal  data”  [laChel¬ 
lo  2008]. 

In  this  report,  we  take  the  dynamic  meaning  of  privacy  as  a  freedom  to  control  an  individual’s 
information.  We  do  not  attempt  to  regulate  how  the  personal  information  is  used  but  rather  to  un¬ 
derstand  the  privacy  implications  of  data  being  stored  and  transferred  in  the  system.  This  meaning 
is  compatible  with  most  literature  on  the  subject. 
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4  Risk  Assessment  Methods 


We  conducted  a  search  of  two  types  of  sources  for  risk  assessment  methods.  We  reviewed  aca¬ 
demic  papers  that  were  written  specifically  to  address  privacy  risk  assessment  or  related  issues, 
and  we  browsed  privacy  regulations  looking  for  sections  that  implicitly  or  explicitly  address  the 
assessment  of  privacy  issues. 

4.1  Literature  Review 

In  “Privacy  and  the  Market  for  Private  Data,”  Yassine  and  Shirmohammadi  discuss  approaches  to 
capitalizing  private  data  assets  [Yassine  2008].  They  propose  a  model  of  privacy  data  negotiation 
between  buyers  and  sellers.  This  means  that  protection  of  privacy  data  is  necessary  only  if  there  is 
a  group  driven  to  buy  the  information. 

In  the  context  of  medical  patient  information.  Buffet  and  Kosa  present  an  analysis  of  risk  in  two 
dimensions:  probability  and  utility  [Buffett  2006]. 

•  Probability  is  the  likelihood  of  a  patient  to  indicate  certain  information.  It  can  come  from  in¬ 
ference  from  the  proportion  of  total  number  of  patients  who  think  that  privacy  is  important. 

•  Utility  is  the  personal  importance  that  the  patient  gives  to  each  information  item. 

While  primarily  addressing  security  issues,  the  Microsoft  Security  Development  Lifecycle  (SDL) 
also  includes  privacy  risk  assessment  as  part  of  the  development  process  [Microsoft  2009b].  In  the 
early  phases  of  the  lifecycle,  the  system  is  divided  into  different  privacy  levels.  In  the  later  phase, 
an  analysis  is  conducted  based  upon  privacy  level. 

•  In  stage  2,  cost  analysis,  a  base  questionnaire  is  given  to  rate  the  privacy  impact  of  the  sys¬ 
tem.  The  system  is  given  a  privacy  impact  rating  (PI,  P2,  or  P3),  which  “measures  the  sensi¬ 
tivity  of  the  data  your  software  will  process  from  a  privacy  point  of  view.” 

•  In  stage  4,  risk  analysis,  a  detailed  privacy  analysis  is  conducted  of  a  project’s  key  privacy 
aspects  [Microsoft  2009a]. 

With  an  approach  similar  to  that  presented  by  Microsoft,  the  Privacy  Impact  Assessment  Guide 
defines  a  threshold  assessment  to  evaluate  the  system’s  overall  privacy  concerns  [OPC  2006].  The 
purpose  of  the  assessment  is  to  determine  whether  the  level  of  privacy  requirements  in  the  system 
necessitate  a  full  privacy  impact  assessment.  The  report  states,  “The  first  critical  question  in  as¬ 
sessing  whether  a  PIA  is  needed  is  whether  any  personal  information  will  be  collected,  used  or 
disclosed  in  the  project.  If  personal  information  is  not  involved  in  the  project  at  any  stage,  the 
project  may  have  a  negligible  impact  on  information  privacy  and  a  PIA  may  not  be  necessary.” 

The  principle  of  proportionality  is  discussed  by  laChello  and  Abowd  as  a  balance  between  priva¬ 
cy  concerns  and  the  utility  of  the  application  [laChello  2005].  They  also  develop  this  idea  into  a 
method  that  is  used  to  aid  HCI  designers  in  designing  applications  with  complex  privacy  implica¬ 
tions.  It  has  four  steps,  which  complete  a  cycle. 

1.  Determine  the  application  goals.  (The  stakeholders  also  need  to  agree  on  the  burden  of  pri¬ 
vacy  issues  and  the  benefits  of  addressing  those  issues.) 

2.  Select  the  appropriate  techniques  or  technologies  to  use. 
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3.  Validate  whether  the  technologies  chosen  are  adequate  for  the  purpose. 

4.  Refine  the  goals  and  start  a  new  cycle  if  necessary. 

Palen  and  Dourish  suggest  a  concept  of  “genres  of  disclosure,”  which  is  another  framework  to  aid 
the  design  of  a  system  with  privacy  concerns.  It  is  based  on  the  observation  that  “privacy  is  not 
simply  a  problem  of  access  control,  but  is  rather  an  ongoing  and  organic  process  of  negotiating 
boundaries  of  disclosure,  identity,  and  time”  [Palen  2003].  They  presented  multiple  case  studies  to 
support  the  idea  that  dynamic  policies  based  on  circumstances  are  more  effective  than  static  poli¬ 
cies  that  always  hold  true. 

Jensen  compares  and  contrasts  different  methods  in  addressing  privacy  risk  concerns  when  de¬ 
signing  software-intensive  systems  [Jensen  2007]. This  includes  his  PhD  dissertation,  the  STRAP 
method  [Jensen  2005]. 

flong  et  al.  propose  a  model  for  designing  ubiquitous  computing  systems  with  privacy  concerns 
[fJong  2004].  They  address  both  privacy  risk  analysis  and  management.  The  goal  of  this  model  is 
“to  help  elucidate  those  needs  and  trust  levels,  refining  privacy  from  abstract  principles  into  con¬ 
crete  issues  that  can  be  acted  upon  in  specific  domains  for  specific  apps.”  The  analysis  is  done  by 
using  series  of  questions  to  elicit  requirements.  The  same  authors  also  wrote  a  paper  on  pitfalls  for 
designers  of  systems  with  privacy  concerns  [Lederer  2003]. 

The  Treasury  Board  of  Canada’s  Privacy  Impact  Assessment  Guidelines  can  be  used  as  a  frame¬ 
work  in  eliciting  privacy  requirements.  The  framework  is  composed  of  three  parts:  need  assess¬ 
ment,  documenting  the  data  flow,  and  privacy  analysis  [TBCS  2002]. 

A  model  of  privacy  breaches  caused  by  human  error  is  presented  in  [Divakaran  2009].  The  au¬ 
thors  apply  the  human  error  model  to  the  system  privacy  model  and  identify  possible  issues. 

The  CERT  OCTAVE®  (Operationally  Critical  Threat,  Asset,  and  Vulnerability  Evaluation®^) 
method  is  a  collection  of  frameworks  and  security  assessment  methods  using  a  risk-based  ap¬ 
proach.  In  the  background  section  of  a  practitioners  report  [Woody  2006],  it  is  noted  that 
OCTAVE  was  developed  to  “apply  the  approach  to  the  security  compliance  challenges  faced  by 
the  U.S.  Department  of  Defense  (DoD)  when  the  security  compliance  portion  of  the  Health  Insur¬ 
ance  Portability  and  Accountability  Act  (HIPAA)  was  mandated.”  Since  HIPAA  deals  directly 
with  information  privacy,  the  tools  and  methods  presented  in  OCTAVE  could  be  useful  in  our 
case  as  well.  Specific  practices  can  also  be  found  in  the  OCTAVE  Catalogue  of  Practices  [Alberts 
2001]. 

4.2  Privacy  Regulations 

Besides  academic  literature  on  privacy  risk  assessments,  many  laws  and  regulations  provide  a  set 
of  guidelines  that  can  be  used  to  assess  privacy  risks.  However,  some  literature  argues  that  the 
guidelines  usually  address  the  system  as  a  whole  but  not  the  interaction  between  different  parties 
passing  sensitive  information.  Some  guidelines  also  seem  to  follow  a  different  meaning  of  priva- 


OCTAVE  is  registered  in  the  United  States  Patent  and  Trademark  Office  by  Carnegie  Mellon  University.  Opera¬ 
tionally  Critical  Threat,  Asset,  and  Vulnerability  Evaluation  is  a  service  mark  of  Carnegie  Mellon  University. 
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cy,  as  stated  in  the  previous  section.  This  is  evident  in  certain  cases  where  the  objective  is  stated 
clearly  to  “protect  privacy”  rather  than  to  empower  the  user’s  control  of  the  information. 

Although  not  ideal,  the  guidelines  provided  hy  different  institutions  give  diverse  viewpoints  on 
the  problem  of  privacy  risk  assessment.  Looking  at  these  guidelines,  we  also  gain  insight  into  the 
components  of  privacy  risk  assessments  which  can  be  used  to  find  opportunities  for  improve¬ 
ments. 

4.2.1  Health  Insurance  Portability  and  Accountability  Act 

The  Health  Insurance  Portability  and  Accountability  Act  (HIPAA)  addresses  privacy  concerns  of 
health  information  systems  by  enforcing  data  exchange  standards.  The  act  also  provides  a  guide¬ 
line  to  analyze  risks.  The  overall  objective  of  a  HIPAA  risk  analysis  is  to  document  the  potential 
risks  and  vulnerabilities  related  to  the  confidentiality,  integrity,  and  availability  of  electronic  pro¬ 
tected  health  information  (ePHI)  and  to  determine  the  appropriate  safeguards  to  bring  the  level  of 
risk  to  an  acceptable  and  manageable  level.  Risks  found  by  the  analysis  fall  into  three  categories: 
access,  storage,  and  transmission. 

The  entities  of  interest  in  HIPAA  are  called  the  “Covered  Entities”  (CEs),  which  must  comply 
with  the  HIPAA  Security  Rule.  These  are  health  plans  (HMOs,  group  health  plans,  etc.),  health 
care  clearinghouses  (billing  and  repricing  companies,  etc.),  and  health  care  providers  (doctors, 
dentists,  hospitals,  etc.)  that  transmit  any  ePHI. 

There  are  seven  steps  in  HIPAA  risk  assessment: 

1.  Inventory  and  classify  assets. 

2.  Document  likely  threats  to  each  asset. 

3.  Conduct  a  vulnerability  assessment. 

4.  Evaluate  current  safeguards  (administrative,  physical,  and  technical). 

5.  Document  risks. 

6.  Recommend  appropriate  safeguards. 

7.  Report  on  results. 

4.2.2  Public  Records  Act 

The  Public  Records  Act  (PRA)  states  that  every  person  has  a  right  to  inspect  any  public  record, 
with  specified  exceptions.  A  University  Electronic  Communications  Record,  for  example,  is  a 
public  record  whether  or  not  any  of  the  electronic  communications  resources  used  to  create,  send, 
forward,  reply  to,  transmit,  distribute,  broadcast,  store,  hold,  copy,  download,  display,  view,  read, 
or  print  the  record  are  owned  by  the  university.  The  university’s  online  service  providers  must 
have  procedures  for  making  their  records  available  in  accordance  with  any  requests  under  the 
PRA,  other  laws,  or  as  a  result  of  litigation. 

This  act  demonstrates  another  view  of  privacy,  as  the  aim  is  not  solely  an  attempt  to  protect  privacy 
but  to  define  it  in  terms  of  access  granted  to  certain  parties  involved  in  the  information  of  interest. 

References 

http://comp-resources.berkeley.edu/privacy/regulations.html 

http://www.atg.wa.gov/OpenGovemment/InternetManual/Chapter2.aspx 
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4.2.3  The  Family  Educational  Rights  and  Privacy  Act 

Family  Educational  Rights  and  Privacy  Act  (FERPA)  regulations  provide  that  educational  agen¬ 
cies  and  institutions  that  receive  funding  under  a  program  administered  hy  the  U.  S.  Department 
of  Education  must  provide  students  with  access  to  their  education  records,  an  opportunity  to  seek 
to  have  the  records  amended,  and  some  control  over  the  disclosure  of  information  from  the 
records.  With  several  exceptions,  schools  must  have  students’  consent  prior  to  the  disclosure  of 
education  records.  Examples  of  situations  affected  hy  FERPA  include  school  employees  divulg¬ 
ing  information  to  someone  other  than  a  child's  parents  about  the  child's  grades  or  behavior,  and 
school  work  posted  on  a  bulletin  board  with  a  grade. 

References 

http://www.ed.gov/policy/gen/guid/fpco/ferpa/index.html 

http://en.wikipedia.org/wiki/Family_Educational_Rights_and_Privacy_Act 

4.2.4  Electronic  Communications  Policy 

A  set  of  rules  is  published  by  University  of  California  addressing  a  privacy  concern  in  electronic 
communication.  The  purposes  of  this  policy  are  to  establish  guidelines  on  privacy,  confidentiality, 
and  security  in  electronic  communications.  Items  to  be  protected  in  this  case  are  personal  informa¬ 
tion,  student  information,  electronically  gathered  data,  and  telephone  conversations.  The  regulations 
identify  the  entities  that  are  allowed  access  to  information  and  those  that  must  be  restricted  from  it. 

References 

http://www.ucop.edU/ucophome/policies/ec/html/pp081805ecp.html#PROVISIONS 

4.2.5  Gramm-Leach-Bliley  Act 

The  main  purpose  of  this  act  is  to  allow  commercial  and  investment  banks  to  consolidate  as  one 
institution.  As  the  banks  are  merged,  the  act  also  specifies  certain  regulations  regarding  financial 
information  privacy.  These  are  the  three  main  components  of  this  act  that  address  privacy: 

•  Financial  Privacy  Rule.  A  financial  institution  must  give  its  customers  privacy  notices  that 
explain  the  institution’s  information  collection  and  sharing  practices.  This  privacy  notice  must 
be  given  to  customers  before  any  business  agreements  can  be  made. 

•  Safeguards  Rule.  The  institution  must  create  a  security  plan  to  protect  the  confidentiality  and 
integrity  of  personal  consumer  information. 

•  Pretexting  Protection.  The  institution  must  protect  personal  information  from  access  without 
an  authority.  This  could  also  be  referred  to  as  protection  from  social  engineering. 

For  a  privacy  dimension  of  this  act,  financial  institutions  must  provide  their  clients  a  privacy  no¬ 
tice  that  explains  what  information  the  company  gathers  about  the  client.  The  responsibility  is  not 
just  explaining  the  changes  but  also  giving  the  customer  the  opportunity  to  opt  out.  This  means 
that  customer  can  say  “no”  to  allowing  their  information  to  be  shared.  Flowever,  there  are  also 
items  that  customers  cannot  choose  to  opt  out  of: 

•  information  shared  with  those  providing  priority  service  to  the  financial  institution 

•  marketing  of  products  and  services  for  the  financial  institution 

•  information  that  is  deemed  legally  required 
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This  law  also  made  a  reference  to  the  Fair  Credit  Reporting  Act,  stating  that  the  privacy  notice 
needs  to  identify  the  right  to  opt  out  to  unaffiliated  parties. 

References 

http://www.ftc.gov/privacy/privacyinitiatives/glhact.html 
FAQ  on  GLBA  http://www.ftc.gov/privacy/glhact/glh-faq.htm 

4.2.6  Fair  Credit  Reporting  Act 

The  Fair  Credit  Reporting  Act  (FCRA)  directly  regulates  the  collection,  dissemination,  and  use  of 
consumer  credit.  Combined  with  the  Fair  Debt  Collection  Practices  Act,  the  FCRA  defines  rights 
to  credit  information.  It  mainly  regulates  how  consumer  reporting  agencies  operate.  A  few  state¬ 
ments  addressing  privacy  concerns  are 

“If  negative  information  is  removed  as  a  result  of  a  consumer’s  dispute,  it  may  not  be  rein¬ 
serted...” 

“Credit  Reporting  Agencies  may  not  retain  negative  information  for  an  excessive  period.” 

As  stated  in  the  above  section,  this  law  complements  the  Gramm-Leach-Bliley  Act  by  addressing 
sharing  information  with  third  parties. 

4.2.7  Campus  Mailing  List  Regulations 

Electronic  mail  certainly  is  another  form  of  digital  data  transfer.  Special  care  must  be  given  to 
email  that  has  the  potential  to  be  viewed  by  many  parties.  Different  universities  state  their  regula¬ 
tions  differently.  For  example.  University  of  California  at  Berkeley  regulations  state  that 

“Mailing  list  managers  must  provide  the  means  for  subscribers  to  find  out  what  level  of  pri¬ 
vacy  protection  is  normally  available  for  addressee  names  included  on  the  list.” 

“List  managers  also  must  advise  their  list  members  that  despite  whatever  settings  are  in  place 
for  normal  access  could  result  in  disclosure  of  list  membership  information.” 

Reference 

http://comp-resources.berkeley.edu/privacy/privacy-guidelines.html 

4.2.8  The  Patient  Safety  and  Quality  Improvement  Act  of  2005 

This  law  creates  “Patient  Safety  Organizations  (PSOs)  to  collect,  aggregate,  and  analyze  confi¬ 
dential  information  reported  by  health  care  providers.”  The  act  is  a  direct  response  to  the  fear  of 
letting  federal  agencies  have  access  to  patient  records. 

The  interesting  characteristic  of  this  law  as  opposed  to  others  is  that  it  does  not  attempt  to  regulate 
any  private  entities.  Rather,  it  defines  how  the  U.S.  government  will  operate  on  sensitive  patient 
information  so  as  to  provide  transparency  in  the  process. 

References 

http://www.ahrq.gov/qual/psoact.htm 

http://www.pso.ahrq.gov/statute/pll09-41.htm 
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4.2.9  Fair  Information  Practices  Act 


The  intent  of  the  Fair  Information  Practices  Act  (FIPA),  a  Massachusetts  state  law,  is  to  ensure 
that  certain  types  of  personal  data  collected  and  held  hy  the  state  government  remain  private  and 
are  disclosed  only  in  accordance  with  applicable  law.  FIPA  also  extends  to  certain  individuals’ 
rights  over  pertinent  state -held  data. 

The  general  idea  of  this  act  exhibits  a  strong  correlation  to  the  Patient  Safety  Act.  Both  laws  are 
not  used  to  regulate  any  other  entity  but  the  government  itself.  FIPA  was  passed  to  ensure  that  the 
government  would  not  abuse  the  privacy  of  its  citizens.  It  also  grants  an  authorization  to  certain 
agencies  to  issue  further  regulations. 

References 

http://www.umass.edu/humres/library/fipa.htm 

http://www.mass.gOv/Ihqcc/docs/meetings/08feb20_presentation_fipa_hipaa.ppt 
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5  Elements  of  Privacy  Risk  Assessment 


As  one  can  observe,  several  aspects  of  privacy  risk  assessment  addressed  in  the  academic  litera¬ 
ture  and  the  laws  above  tend  to  focus  on  a  certain  area  of  interest.  To  be  able  to  formulate  a 
framework  for  privacy  risk  assessment,  we  need  a  complete  view  of  the  process. 

We  need  a  way  to  classify  each  piece  of  literature  into  an  area  of  concern  in  risk  assessment.  Ac¬ 
cording  to  Barry  Boehm,  risk  assessment  has  three  major  components  [Boehm  1991]: 

1 .  Risk  Identification.  The  project-specific  risks  are  generated  using  various  identification 
techniques. 

2.  Risk  Analysis.  After  risks  are  detected  in  the  identification  step,  certain  properties  are  as¬ 
signed  to  each  risk  statement  so  that  they  can  be  distinguished  by  group. 

3.  Risk  Prioritization.  A  ranked  order  of  risks  is  produced  in  order  to  show  their  importance. 

Using  these  steps  as  a  guideline,  we  classify  each  document  by  the  components  of  risk  assessment 
it  addresses.  (See  Table  1  and  the  classification  scheme  that  follows  it.)  We  can  then  select  the 
pieces  and  assemble  a  complete  risk  assessment  technique. 

Table  1 :  Classification  of  Papers  and  Regulations  by  Risk  Assessment  Category 


Type 

Publication  /  Regulation  (numbers  correspond  to  classification  details  below) 

Risk  Identification 

[3][4][5][6][7][8][9][10][11][12][16][17] 

Risk  Anaiysis 

[1  ][2][4][7][8][9][1  1  ][1 3][1 4][1 5][1 8],[1 9], [20] 

Risk  Prioritization 

[1][7][8] 

5.1  Classification  Details 

1 .  Privacy  and  the  Market  for  Private  Data:  A  Negotiation  Model  to  Capitalize  on  Private  Data 

See  Section  5.2  -  Data  Classifications  and  Risk  Quantification. 

In  Section  6,  the  authors  use  game  theory  to  model  the  relationship  between  information 
buyers  and  sellers. 

2.  Towards  a  Model  for  Risk  and  Consent  Management  of  Private  Health  Information 

See  Section  V  -  Risk  Analysis. 

3.  Microsoft  Security  Development  Lifecycle  (SDL) 

For  Stage  2:  Cost  Analysis  -  Privacy  Requirements,  we  need  to  classify  the  system  into 
one  of  the  three  privacy  levels. 

For  Stage  4:  Conduct  Risk  Analysis  based  on  privacy  level. 

4.  Privacy  Impact  Assessment  Guide 

Section  14  demonstrates  how  to  map  the  information  flow  in  the  system. 

Section  15  presents  a  series  of  questions  used  to  elicit  areas  of  risk  but  provides  no  guid¬ 
ance  on  how  to  prioritize  them. 

5.  Privacy  and  Proportionality:  Adapting  Legal  Evaluation  Techniques  to  Inform  Design  In 
Ubiquitous  Computing 

Explains  the  principle  of  proportionality  in  relation  to  privacy. 

6.  Unpacking  “Privacy”  for  a  Networked  World 
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Provides  a  general  understanding  that  privacy  requirements  are  dynamic. 

7.  Experimental  Evaluation  of  a  Lightweight  Method  for  Augmenting  Requirements  Analysis 

Proposes  the  STRAP  method  for  assessing  privacy  risks  and  guiding  the  design  process. 

8.  Privacy  Risk  Models  for  Designing  Privacy-Sensitive  Ubiquitous  Computing  Systems 

Proposes  a  complete  privacy  risk  model  for  ubiquitous  computing. 

9.  Privacy  Impact  Assessment  Guidelines:  A  Eramework  to  Manage  Privacy  Risks 

Presents  a  data  flow  table. 

Discusses  privacy  analysis  in  a  separate  section. 

10.  How  Significant  Is  Human  Error  as  a  Cause  of  Privacy  Breaches?  An  Empirical  Study  and  a 
Eramework  for  Error  Management 

This  is  not  directly  related  to  risk;  it  considers  human  errors  that  cause  privacy  breaches. 
However,  we  might  have  a  way  to  map  human  error  behavior  onto  risk. 

11.  Operationally  Critical  Threat,  Asset,  and  Vulnerability  Evaluation  (OCTAVE) 

12.  Health  Insurance  Portability  and  Accountability  Act  (HIPAA) 

13.  Public  Records  Act  (PRA) 

14.  The  Eamily  Educational  Rights  and  Privacy  Act  (EERPA) 

15.  Electronic  Communications  Policy 

16.  Gramm-Leach-Bliley  Act 

17.  Pair  Credit  Reporting  Act  (PCRA) 

18.  Campus  Mailing  List  Regulations 

19.  The  Patient  Safety  and  Quality  Improvement  Act  of  2005 

20.  Pair  Information  Practices  Act  (PIPA) 
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6  Case  Studies 


6.1  Case  Study  1 

A  research-oriented  school  in  a  university  needs  a  tool  to  help  manage  the  awards  that  they  re¬ 
ceive  for  research  activities.  A  research  activity  is  one  that  will  advance  the  knowledge  in  the  dis¬ 
cipline;  an  award  is  a  grant  that  is  given  to  the  researcher  to  conduct  the  research.  The  tool  is  ex¬ 
pected  to  help  researchers  and  their  business  manager  in 

•  handling  the  proposal  process  for  winning  awards 

•  importing  human  resources  and  accounting  data  to  aid  in  forecasting 

•  tracking  and  forecasting  the  amount  of  funding  spent 

•  certifying  the  effort  of  the  researchers  that  work  on  a  research  activity 

In  order  to  create  a  proposal  and  do  the  forecasting,  the  system  needs  to  use  this  data: 

•  HR  data,  including  salaries  and  effort  of  each  staff  member 

•  nature  of  the  research  in  the  proposal 

6.2  Case  Study  2 

A  fitness  consulting  firm  that  provides  health  fitness  solutions  to  its  clients  collects  the  testing 
data  of  the  clients  and  recommends  a  coaching  program  based  on  their  metabolic  activity.  The 
project  basically  involves  the  development  of  a  web-based  application  to  automate  the  following 
processes: 

•  collecting  medical  data 

•  managing  the  database 

•  providing  customized  reports  of  patient  data 

The  following  are  the  types  of  data  handled  through  the  application: 

•  heart  rate,  blood  pressure,  metabolic  activity 

•  body  measurements  such  as  height,  weight,  and  girth 

•  food  patterns  (breakfast  time,  lunch  time  and  dinner  time) 


13  I  CMU/SEI-2009-SR-017 


7  Selected  Risk  Assessment  Techniques 


One  of  the  techniques  used  for  both  of  the  above -mentioned  projects  was  the  risk  model  devel¬ 
oped  for  ubiquitous  computing.  The  model  is  composed  of  two  parts.  The  first  is  a  risk  analysis 
that  poses  a  series  of  questions  to  help  designers  refine  their  understanding  of  the  problem  space. 
The  second  part  looks  at  privacy  risk  management,  which  deals  with  categorizing,  prioritizing, 
and  developing  interaction  techniques,  architectures,  and  strategies  for  managing  potential  privacy 
risks. 

7.1  Privacy  Risk  Anaiysis  for  Ubiquitous  Computing 

The  first  part  of  the  privacy  risk  model  is  a  set  of  questions  intended  to  help  design  teams  think 
through  specific  privacy  issues  for  ubiquitous  computing  applications.  The  output  from  this  analy¬ 
sis  should  be  an  unordered  list  of  potential  privacy  risks.  The  questions  are  organized  into  two 
groups,  looking  at  the  social  and  organizational  context  in  which  the  application  is  embedded  and 
the  technology  used  in  implementing  that  application. 

The  second  part  of  the  privacy  risk  model  looks  at  privacy  risk  management,  which  takes  the  un¬ 
ordered  list  of  privacy  risks  from  the  privacy  risk  analysis,  prioritizes  them,  and  helps  design 
teams  identify  solutions  for  helping  end  users  manage  those  issues  (through  technical  solutions, 
social  processes,  or  other  means).  This  privacy  risk  management  is  based  on  the  concept  of  rea¬ 
sonable  care  in  law:  “the  degree  of  care  that  makes  sense  and  that  is  prudent,  enough  but  not  too 
much”  [Feinman  2000].  This  model  uses  Hand’s  cost-benefit  analysis  [Hand  1947],  which  con¬ 
siders  three  factors  for  use  in  managing  privacy: 

1 .  the  likelihood  L  that  an  unwanted  disclosure  of  personal  information  occurs 

2.  the  damage  D  that  will  happen  on  such  a  disclosure 

3.  the  cost  C  of  adequate  privacy  protection 

This  model  also  proposes  to  use  a  qualitative  assessment  of  high,  medium,  and  low  to  help  gauge 
each  of  these  factors,  though  we  used  a  numerical  scale  to  quantify  the  values.  In  general,  situa¬ 
tions  where  C  <  LD,  that  is,  where  the  risk  and  damage  of  an  unwanted  disclosure  outweigh  the 
costs  of  protection,  suggest  that  privacy  protections  should  be  implemented. 

After  identifying  and  prioritizing  the  privacy  risks  (based  on  likelihood  and  damage),  it  is  useful 
to  think  about  how  to  manage  those  risks. 

7.1 .1  Case  Study  1  -  Proposal  Tool 

In  the  interview,  a  series  of  questions  were  posed  to  the  project  representative.  A  summary  of  the 
interview  is  given  below. 

Data  observer:  Sponsor’s  project  accountant 

Direct  users:  Business  manager  (BM),  project  implementer  (PI),  administrator 

Data  sharers:  PI  and  BM  share  data  with  each  other;  dean  and  Office  of  Sponsored  Projects 
(OSP)  shares  data  with  accountant 
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Information  shared:  Address,  salary,  and  effort  of  each  employee 
When  it  is  shared:  When  the  budget  is  sent  for  approval 

Relationship  between  data  observers,  sharers:  PI  and  BM,  social;  sponsor  and  OSP,  legal 

Malicious  observers:  Credit  card,  marketing,  and  financial  companies  might  be  interested  in  sala¬ 
ry  data;  competitors  might  be  interested  in  project  data 

Stakeholders:  Researchers,  part-time  programmers,  staff  who  will  conduct  each  proposed  project 
Data  retention:  Permanent 

As  part  of  the  risk  analysis,  the  first  step  is  to  identify  the  risks.  The  following  were  the  risks  iden¬ 
tified  after  the  interview. 

1 .  Data  is  being  shared  with  the  OSP  users  and  it  is  not  clear  who  the  users  are.  The  information 
might  end  up  being  shared  with  untrusted  users. 

2.  Sharers’  addresses,  salaries,  and  effort  on  each  project  are  being  uploaded  to  a  website,  which 
might  cause  the  information  to  be  pulled  by  malicious  users. 

3.  There  are  no  incentives  for  protecting  personal  information. 

4.  The  university’s  competitors  could  be  the  malicious  observers  that  may  end  up  giving  out  infor¬ 
mation  to  credit  card  companies  and  marketing  companies,  which  in  turn  will  result  in  loss  of 
business  to  the  university. 

5.  Data  that  is  permanently  stored  on  university  servers  might  result  in  information  being  pulled 
from  present  and  past  projects. 

After  identifying  and  agreeing  with  the  identified  risks,  the  team,  along  with  the  project  represent¬ 
ative,  discussed  the  risks  and  then  prioritized  them  using  Hand’s  cost-benefit  analysis. 

The  following  values  were  used  for  prioritizing  the  risks. 

Likelihood  and  damage 

3  -  High 
2 -Med 
1  -  Low 

Cost 

Cost  values  range  from  1—9,  where  1  means  the  cost  of  implementing  measures  is  low  and  9 
means  it  is  very  high. 
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Risk  ID 

Likelihood 

Damage 

Cost 

1 

2 

3 

4 

2 

2 

3 

7 

3 

3 

3 

6 

4 

1 

3 

4 

5 

1 

3 

8 

Likelihood  and  damage  values  were  determined  by  the  project  representative,  and  the  cost  values 
were  determined  by  the  team. 

7.1 .2  Case  Study  2  -  Fitness  Consulting  Tool 

In  the  interview,  a  series  of  questions  were  posed  to  the  project  representative.  A  summary  of  the 
interview  is  given  below. 

Data  observer:  Case  manager,  dietician,  exercise  specialist,  and  administrator  (has  access  to  the 
database) 

Direct  users:  Case  manager  (testing  and  data),  dietician  (analysis  and  recommendations),  exer¬ 
cise  specialist  (suggesting  exercise  routines) 

Data  sharer:  Patient 

Information  shared:  Measurements,  date  of  birth,  first  name  and  last  name,  and  other  testing 
details  such  as  heart  rate 

Circumstance  under  which  data  is  shared:  When  the  patient  wants  recommendations,  the  case 
manger  enters  the  data;  once  the  data  is  in  the  database,  others  users  can  view  the  data 

Malicious  observers:  None 

Data  is  shared  because:  More  testing  values  lead  to  more  recommendations 
Incentives  for  protecting  data:  They  might  lose  business  if  customers  sue  or  lose  trust 

Level  of  trust  of  people  who  are  sharing  the  information:  Business  relationship 

Kind  of  personal  information  people  might  be  interested  in:  Date  of  birth,  first  and  last  name, 
testing  details 

Data  retention:  12  months  (after  that,  the  client  doesn’t  know  what  is  done  with  the  data) 

Personal  information  collection  source:  Web-enabled  user  interface  and  external  device  that  is 
fixed  to  the  body.  Main  entry  point:  case  manager  enters  data  into  the  system  on  behalf  of  the 
client.  One  way  is  manual  and  other  is  automated. 

Who  has  control?  Three  users,  and  system  admin  has  control  of  the  database 
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How  it  is  shared?  Case  manager  enters  the  data  and  then  other  users  view  the  data  from  the  en¬ 
tered  source 

Push  or  pull?  Case  manager  pushes  the  data  and  others  users  can  pull  the  required  information 

Opt  in  or  opt  out?  Data  sharers  can  view  only  the  required  data  (depending  on  the  visiting  pa¬ 
tient) 

Information  sharing?  Patient  details  can  be  viewed  by  the  case  manager  at  any  time 

Data  uploading?  Continuous  and  done  at  various  times 

Data  storage?  Office  location 

Access  to  data  location?  System  admin 

The  first  step  in  the  risk  analysis  is  to  identify  the  risks.  The  following  were  the  risks  identified 
after  the  interview. 

1 .  All  data  observers  have  access  to  many  types  of  personal  information  of  the  patient  and 
might  cause  the  information  to  be  used  inappropriately. 

2.  All  personal  information  shared  is  static  information,  which  might  result  in  revealing  the 
user’s  identity. 

3.  There  is  no  value  proposition  for  all  the  data  observers  to  share  the  patient’s  personal  infor¬ 
mation;  the  exercise  specialist,  dietitian,  or  administrator  may  give  the  information  to  outside 
users. 

4.  Collecting  data  sharers’  information  through  network-based  or  network-assisted  approaches 
might  result  in  less  security  protection  of  the  users’  information. 

5.  A  pull  mechanism  is  used,  so  it  introduces  more  risk  and  might  result  in  all  of  a  user’s  in¬ 
formation  being  retrieved  from  the  database. 

6.  The  data  retention  period  is  defined,  but  after  that  the  client  does  not  clearly  know  what  will 
happen  to  the  data.  Information  of  present  and  past  clients  might  be  pulled. 

After  identifying  and  agreeing  with  the  identified  risks,  the  team,  along  with  the  project  represent¬ 
ative,  prioritized  the  risks  using  Hand’s  cost-benefit  analysis. 

The  following  values  were  used  for  prioritizing  the  risks. 

Likelihood  and  damage 

3  -  High 
2 -Med 
1  -  Low 

Cost 

Cost  values  range  from  1—9,  where  1  means  the  cost  of  implementing  measures  is  low  and  9 
means  it  is  very  high. 
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Risk  ID 

Likelihood 

Damage 

Cost 

1 

2 

3 

4 

2 

2 

2 

6 

3 

3 

2 

8 

4 

3 

3 

3 

5 

3 

3 

4 

6 

3 

3 

3 

Likelihood  and  damage  values  were  determined  by  the  project  representative,  and  the  cost  values 
were  determined  by  the  team. 

7.1.3  Reflections 

This  approach  only  expresses  what  factors  should  be  taken  into  account.  The  values  of  these  fac¬ 
tors  are  judgment  calls  based  on  the  best  knowledge  that  the  design  team  has. 

This  approach  does  not  address  extreme  cases;  instead  it  looks  at  risks  that  are  foreseeable  and 
significant. 

The  utility  of  this  cost-benefit  analysis  comes  not  so  much  from  accurate  and  precise  values  as 
from  having  the  design  team  think  through  the  issues  of  likelihood,  damage,  and  cost. 

This  approach  addresses  relatively  few  security  issues.  It  should  be  used  in  conjunction  with  a 
security  threat  model  to  ensure  that  the  desired  privacy  needs  are  properly  implemented  and  se¬ 
cured. 

7.2  Structured  Analysis  of  Privacy 

The  second  risk  assessment  methodology  we  adopted  was  the  Structured  Analysis  of  Privacy 
(STRAP)  methodology.  STRAP  is  designed  to  strike  a  balance  between  the  robustness  of  re¬ 
quirements  engineering  based  techniques  and  the  flexibility  and  ease  of  use  of  heuristics-based 
approaches.  STRAP  combines  these  two  methods,  goal-oriented  analysis  and  heuristic  evaluation, 
in  an  effort  to  improve  the  quality  and  effectiveness  of  the  analysis  while  keeping  the  costs  down. 

STRAP  is  primarily  aimed  at  supporting  designers  and  analysts  in  dealing  with  privacy  in  the  ear¬ 
ly  phases  of  design  when  functionality  is  still  being  decided  and  fundamental  design  decisions  can 
still  be  changed  or  influenced.  STRAP  is  also  specifically  aimed  at  dealing  with  the  HCI  problems 
associated  with  privacy  awareness  and  management.  This  means  that  the  heuristics  used  are  spe¬ 
cifically  targeted  to  dealing  with  these  issues.  This  does  not  mean  that  STRAP  will  not  be  useful 
in  analyzing  and  discovering  other  types  of  privacy  problems,  although  this  is  a  question  that  will 
have  to  be  determined  experimentally. 

Specifically,  STRAP  uses  a  goal-oriented  analysis  technique  to  structure  the  problem  space,  en¬ 
suring  a  thorough  and  balanced  analysis,  and  uses  lightweight  and  efficient  heuristics  to  identify 
potential  privacy  problems,  suggest  solutions  or  design  refinements,  and  finally  help  the  analysts 
evaluate  these  refinements. 
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7.2.1  Goal-Oriented  Analysis  in  STRAP 


Goal-oriented  analysis  is  a  technique  typically  associated  with  requirements  engineering  [Dar- 
denne  1993].  It  is  used  to  elicit  system  requirements  and  structure  how  analysts  and  designers 
think  about  a  system  early  in  the  design  process.  In  goal-oriented  analysis,  the  analyst  identifies 
the  systems  goals  from  a  users’  perspective  by  studying  users  and  the  way  they  interact  with  each 
other,  the  systems,  artifacts,  and  the  environment.  From  these  observations,  requirements  can  be 
identified,  either  directly  or  by  deriving  scenarios  and  use  cases  which  illustrate  typical  as  well  as 
critical  functions  or  tasks.  In  this  role,  goal-oriented  analysis  can  be  used  to  structure  and  analyze 
complex  sets  of  observational  or  unstructured  data.  After  identifying  key  goals  and  functions, 
these  are  broken  down  into  increasingly  simple  component  subgoals,  much  in  the  same  way  as  in 
the  GOMS  method  [John  1996].  This  process  continues  until  the  subgoals  are  trivially  simple  and 
further  breakdown  is  counterproductive.  An  alternative  definition  of  how  far  a  set  of  goals  need  to 
be  decomposed  is  that  all  leaf-goals  must  be  assignable  to  a  single  actor.  In  other  words,  all  leaf- 
goals  must  be  so  simple  that  a  single  entity  or  system  can  fulfill  them  completely.  Until  the  analy¬ 
sis  reaches  this  level,  implementation  details  and  necessary  decisions  will  likely  be  hidden  or  lost 
in  the  analysis. 

7.2.2  Vulnerability  Analysis  Using  STRAP 

Using  the  goal  tree  derived  in  the  previous  step  as  a  blueprint  or  checklist  of  the  functionality  to 
consider,  an  analyst  can  set  out  to  identify  potential  privacy  vulnerabilities.  Both  heuristic -based 
and  requirements  engineering  analysis  methods  commonly  rely  on  a  small  set  of  analytical  ques¬ 
tions  to  identify  potential  problems  (see  Figure  6  in  [Bellotti  1993]  or  Figure  7  in  [Hong  2004]  for 
examples).  For  STRAP,  these  questions  were  derived  from  Bellotti  and  Sellen,  as  well  as  a  review 
of  the  information  life  cycle,  potential  sources  of  information  misuse,  and  the  kinds  of  questions 
users  have  about  companies’  information  practices.*  For  each  goal  and  subgoal,  the  designer 
should  ask  the  following  questions  to  determine  the  information  capture  and  use: 

•  What  information  is  captured,  accessed,  processed,  transmitted,  received,  or  stored  in  meeting 
this  goal? 

•  How  is  the  information  captured,  accessed,  processed,  transmitted,  received,  or  stored? 

•  Who  are  the  actors  involved  in  the  capture,  access,  processing,  transmission,  receipt,  or  sto¬ 
rage? 

•  What  knowledge  is  derived  from  this  information? 

•  What  is  done  with  the  information  and  meta-information  after  the  goal  is  met? 

If  information  is  captured,  accessed,  processed,  transmitted,  received,  or  stored,  this  may  present 
privacy  vulnerability.  Vulnerabilities  are  marked  in  the  goal  tree  as  clouds  over  the  path  to  the 
goal.  By  placing  these  vulnerabilities  in  the  diagram,  we  preserve  context  information;  we  know 
what  goals  these  problems  are  associated  with  and  what  actors  are  involved.  This  helps  give  the 
designers,  programmers,  and  users  a  shared  vocabulary  for  discussing  the  system.  Furthermore, 
when  goals  are  finally  translated  into  requirements,  functions,  and  eventually  system  components, 
we  can  trace  how  these  vulnerabilities  are  addressed  or  will  affect  different  system  components. 


Earp,  J.  B.  &  Meyer,  G.  “Internet  Consumer  Behavior:  Privacy  and  its  Impact  on  Internet  Policy,”  28th  Tele¬ 
communications  Policy  Research  Conference,  September  2000. 


19  I  CMU/SEI-2009-SR-017 


Once  vulnerabilities  have  been  identified,  we  look  for  common  causes  and  duplicate  vulnerabili¬ 
ties.  These  often  occur  when  one  set  of  goals  collect,  transmit,  or  store  data  needed  to  meet  a  dif¬ 
ferent  set  of  goals.  The  vulnerability  will  then  appear  in  two  or  more  places  on  the  goal  tree,  with 
different  contexts.  If  the  vulnerability  associated  with  the  transmission  of  data  is  addressed 
through  the  encryption  of  that  data,  then  the  vulnerability  associated  with  receiving  the  informa¬ 
tion  will  also  be  addressed.  These  duplicates  are  important  to  identify,  not  simply  because  it  sim¬ 
plifies  the  analyst’s  job  later  on,  reducing  the  number  of  vulnerabilities  to  address,  but  because  it 
affects  the  cost-benefit  analysis  which  should  be  a  part  of  the  decision  about  which  issues  to  ad¬ 
dress. 

7.2.3  Case  Study  1  -  Proposal  Tool 
Create  Goal  Tree 

Since  there  were  complex  interactions  between  various  users  in  this  system,  the  development 
team  originally  used  contextual  design  [Beyer  1998]  as  an  elicitation  technique.  We  found  that  the 
sequence  diagram  helped  in  constructing  the  goal  tree.  The  activity  and  intent  column  of  the  se¬ 
quence  model  intuitively  maps  to  each  goal  and  subgoal,  as  shown  in  Figure  1 . 


Figure  1:  Goal  Tree  Constructed  for  Case  Study  1 


Goal  4:  Gather  Initial  Information 


What? 

Project  name,  principal  investigators,  details  of  the  project  known  to  date 

How? 

Email 

Who? 

Principal  investigator 
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Derived  Know¬ 
ledge? 

Salary  of  PI,  nature  of  research  for  each  PI 

Activities  per¬ 
formed  after  data 

collection 

Cross  check  the  requirements  with  sponsor’s  website 

Goal  5:  Set  Up  the  Budget 


What? 

Project  spending  budget 

How? 

Look  at  the  published  standard  rates  and  posted  salary  list 

Who? 

Business  manager 

Derived  Know¬ 
ledge? 

The  university’s  research  spending  for  each  department 

Activities  per¬ 
formed  after  data 

collection 

" 

Goal  6:  Refine  the  Budget 


What? 

Project  spending  budget 

How? 

Email  to  the  PI 

Who? 

Business  manager 

Derived  Know¬ 
ledge? 

The  university’s  research  spending  for  each  department 

Activities  per¬ 
formed  after  data 

collection 

” 

Goal  8:  Obtain  Internal  Approval 


What? 

Project  spending  budget;  list  of  personnel  involved 

How? 

Send  a  printed  package  to  the  office  of  the  project  sponsor 

Who? 

Business  manager,  office  of  project  sponsor 

Derived  Know¬ 
ledge? 

The  university’s  research  spending  for  each  department 

Activities  per¬ 
formed  after  data 

Check  validity  of  the  proposed  project  budget 
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collection 


Goal  9:  Prepare  Sponsor  Information 


What? 

Project  spending  budget,  list  of  personnel  involved,  budget  justification 

How? 

Apply  via  website 

Who? 

Business  manager,  principal  investigator 

Derived  Know¬ 
ledge? 

Techniques  that  will  be  use  to  approach  particular  problems;  research 
spending  for  each  project  and  Pi’s  salary 

Activities  per¬ 
formed  after  data 

collection 

" 

Goal  12:  Create  a  Project  in  Database 


What? 

Project  schedule  and  equipment  lists 

How? 

Telephone 

Who? 

Business  manager,  office  of  accounting  staff 

Derived  Know¬ 
ledge? 

All  equipment  essential  to  the  success  of  the  research;  project  schedule 

Activities  per¬ 
formed  after  data 

collection 

Create  an  entry  in  the  database  for  project  tracking 

Goal  15:  Update  Monthly  Project  Data 


What? 

Monthly  project  spending  data 

How? 

Published  reports  or  database  query 

Who? 

Business  manager,  office  of  accounting  staff 

Derived  Know¬ 
ledge? 

All  equipment  essential  to  the  success  of  the  research;  project  schedule 

Activities  per¬ 
formed  after  data 

collection 

Create  an  entry  in  the  database  for  project  tracking 

Goal  16:  Discuss  Project  Status 
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What? 

Project  spending  data  to  date 

How? 

Discussion 

Who? 

Business  manager,  principal  investigator 

Derived  Know¬ 
ledge? 

Overall  project  status;  prediction  of  success  or  failure  of  the  project 

Activities  per¬ 
formed  after  data 

collection 

Make  adjustments  to  a  project’s  budget  as  necessary 

Goal  17:  Certify  Effort 


What? 

Reported  effort  data 

How? 

Report  by  the  database  system 

Who? 

Business  manager,  principal  investigator 

Derived  Know¬ 
ledge? 

Predict  personnel  schedule 

Activities  per¬ 
formed  after  data 

collection 

" 

Apply  Design  Heuristics 

After  analyzing  vulnerabilities  in  performing  each  goal,  we  can  apply  design  heuristics  on  them, 
as  shown  in  Figure  2. 
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Figure  2:  Goal  Tree  for  Case  Study  1  with  Design  Heuristics  Applied 

7.2.4  Case  Study  2  -  Fitness  Consulting  Tool 
Create  Goal  Tree 

The  goal  tree  for  this  case  study,  as  opposed  to  case  study  1,  needed  to  he  created  from  scratch. 
We  conducted  an  informal  interview  with  the  system’s  developer  and  documented  the  goal  tree 
shown  in  Figure  3. 
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e  Healthy 


Reduce 

Weight 


'Know  How' 
Should  I  Eat 


^vaiuati^ 


Gather 

Personal 

□formatioj^ 


Figure  3:  Goal  Tree  of  Case  Study  2,  Elicited  from  the  System's  Developers 


Capture  Vulnerabilities 

Goal  4.1:  Gather  Personal  Information 


What? 

First  name,  last  name,  birth  date,  gender 

How? 

Talking  to  clients 

Who? 

Case  manager,  client 

Derived  knowledge? 

(  Does  not  have  sufficient  domain  knowledge  to  answer  questions) 

Activities  performed  after 
data  collection 

- 

Activities  performed  after 
data  collection 

- 

Goal  4.2:  Gather  Physical  Information 


What? 

Height,  weight,  breathing  measurements,  heart  rate 

How? 

Using  instruments  to  measure 
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Who? 

Case  manager,  client 

Derived  knowledge? 

(  Does  not  have  sufficient  domain  knowledge  to  answer  questions) 
Personal  data  for  insurance  company,  perhaps? 

Activities  performed  after 
data  collection 

Use  this  data  to  analyze  the  exercise  and  diets  for  the  patient 

Goal  4.3:  Input  Data 


What? 

All  data  from  goals  4. 1  and  4.2 

How? 

Manual  entry  to  the  system 

Download  from  the  equipment  to  Excel  file  and  upload  Excel  file  to  the 
system 

Report  out  for  the  patient 

Who? 

Case  Manager 

Derived  knowledge? 

(  Does  not  have  sufficient  domain  knowledge  to  answer  questions) 

Personal  data  for  insurance  company,  perhaps? 

Activities  performed  after 
data  collection 

Use  the  data  to  analyze  the  exercise  and  diets  for  the  patient 

Notes 

The  data  could  reside  in  the  devices.  The  only  data  that  is  on  the  device  are 
measured  data  and  gender. 

Goal  8:  Consult  Dietician 


What? 

All  information  from  goal  4.3;  collect  food  preferences 

How? 

View  the  information  through  the  system  web  interface 

Can  only  view,  but  not  edit 

Manual  entry  of  food  preferences  into  the  system 

Who? 

Dietician  and  patient 

Derived  knowledge? 

The  diet  preferences  of  the  patient 

Activities  performed  after 
data  collection 

Use  other  external  resources  for  calculations;  provide  consulting 

Notes 
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Apply  Design  Heuristics 

After  analyzing  the  goals,  we  annotated  the  goal  tree  with  suggested  design  heuristics  to  address 
each  goal’s  specific  problem,  as  shown  in  Figure  4. 


>Jotice/Awareness 
\^ake  user  aware  of 
jata  gathered 


Gather 

Personal 

□formatiqj 


Figure  4:  Goal  Tree  for  Case  Study  2  with  Design  Heuristics  Applied 

7.2.5  Reflections 

This  approach  did  not  address  how  to  prioritize  the  identified  risks. 

This  approach  is  more  comprehensive  than  the  first  method;  that  is,  the  approach  works  toward 
identifying  the  goals,  which  helps  the  analysts  to  be  more  focused. 

Creating  a  goal  tree  that  is  useful  for  analysis  can  be  challenging.  However,  a  project  that  docu¬ 
ments  system  user  intent  and  activities  as  a  part  of  requirement  elicitation  helps  in  creating  a  goal 
tree.  In  case  study  1,  the  flow  of  activities  is  captured  using  the  contextual  design  sequence  model 
[Beyer  1998].  The  goal  can  be  easily  derived  from  the  intent  of  each  activity  in  the  model. 
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8  Summary  and  Future  Plans 


In  this  report  we  have  descrihed  the  application  of  several  privacy  risk  assessment  approaches  to 
two  actual  case  study  projects.  We  started  with  definitions  of  privacy  and  a  survey  of  privacy  risk 
assessment  methods.  We  then  discussed  a  way  to  classify  the  risk  assessment  methods,  followed 
by  classification  of  the  methods.  We  selected  two  risk  assessment  methods.  Privacy  Risk  Analysis 
for  Ubiquitous  Computing  and  STRAP,  to  apply  to  the  case  studies.  For  each  case  study  we  re¬ 
flected  on  the  results  of  the  analysis.  Neither  approach  was  ideal,  suggesting  that  perhaps  a  differ¬ 
ent  approach  or  combination  of  approaches  is  needed  to  get  maximum  benefit.  This  will  be  consi¬ 
dered  as  we  move  forward  in  the  research. 

This  work  is  one  of  the  activities  that  we  have  undertaken  to  extend  SQUARE  to  include  privacy 
considerations  (P-SQUARE).  We  plan  to  continue  our  privacy  risk  assessment  experiments  and 
also  to  revisit  other  SQUARE  steps  to  see  what  modifications  are  needed  for  privacy. 
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